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(54) System for user control of version synchronization in mot>iie computing 

(57) A universal system is provided for synchroniz- 
ing servers which accommodates wide area mobile 
corrputing while at the same time making the process 
more efficient. The system includes a network of pri> 
mary servers with high performance reliable links mak- 
ing up the backbone of the synchronization process to 

which secondary servers are linked via typically less <; 
reliable finks. Moreover, synchronization from a mobile 
computer can be done whether in client/ server mode, 
or peer-to-peer to support any topology of secondary 
servers. In one emtxxliment while the primary servers 
are automatically and frequently synchronized, syn- 
chronization of the secondary servers is under the con- 
trol of the user which prevents unintended 
synchronization. A summarizing version vector is used 
to minimize the anfv>unt of data transmitted by avoiding 
the necessity for exchanging version vectors for individ- 
ual objects. This summarizing version vector also per- 
mits differential synchronization using summarizing 
version vectors and update stamps, the generation of a 
latest common version vector to purge off differential 
updates on a server, restart of synchronization from the 
point of previous failure with data from an unaffected 
server, and fine grain synchronization by permitting a 
differential update as the atom of data to be transmitted. 
Additionally, the system automatically switches between 
whole object synchronization and differential synchroni- 
zation. Further, the subject system permits synchroni- 
zation between different systems because the 
semantics of the data is segregated from the synchroni- 
zation due to extracting updates in a standard format 
and synchronizing based on a standard protocol. 
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Description 

BACKGROUN D OF THE INVENTIQM 

[0001 ] It will be appreciated that with the proliferation 
of mobile computing in the form of laptops and the gen- 
eration of versions of data at various points, there is a 
need to be able to synchronize the versions of the data 
created at multiple locations. This version synchroniza- 
tion must take place over a variety of different platforms 
as individuals move from location to location, state to 
state, and country to country. 

[0002] When multiple users work on the same version 
of a document or data, in the past there have been var- 
ious ways of reconciling the documents. Many systems 
have been provided to alert one user to the fact that 
another document has been altered and to either 
update with the latest version or reject the latest version 
at the user*s discretion. Log files have been used in the 
past to ascertain the time that a version was generated 
and version vectors have been utilized for some time to 
detect conflicts between object replicas. 
[0003] As will be appreciated, there have been several 
approaches_to_the detection-of resolving update con-- 
flicts such as described by' James J. KISTLER et al., 
Disconnected Operation in the CODA File System. 
ACM Transactions on Computer Systems. 10(1), 1992; 
Peter Reiher et al.. Resolving File Conflicts in the Reus 
File System, in USENIX Conference Proceedings. USE- 
NIX. June 1994; and. Douglas B. Teny et al.. Managing 
Update Conflicts in Bayou, a Weekly Connected Repli- 
cated Storage System, in Proceedings of the Fifth Sym- 
posium on Operating System Principles, ASM. 
December 1995. The CODA and Reus systems utilize 
version vectors to detect conflicts between object repli- 
cas as first proposed by D. Stott Parker et al.. Detection 
of Mutual Inconsistency in Distributed Systems. IEEE 
Transactions on Software Engineering 9(3). May 1993. . 
where the Bayou system does not detect conflicts itself, 
but rather relies on the application. 
[0004] Conflict detection utilizing version vectors has 
evolved Into two basic paradigms. One paradigm, as 
exemplified by Reus, involves utilizing a version vector 
to characterize an irKlividual object replica's current 
state relative to other replicas. Another paradigm which 
can be inferred by the CODA system is applying version 
vectors to tMh object replicas and the replication unit 
that contains the set of objects. 
[0005] With respect to the CODA system it will be 
appreciated that it is a file replication system which does 
not support peer>to-peer synchronization. It is in 
essence a client/server system which will not allow two 
clients to synchronize directly with each other. For 
example, if two mobile users want to exchange each 
other's data this must be a peer-to-peer synchronization 
if they didnt know each other before. The only way two 
such clients can possibly synchronize their data is via a 
common server. If the two clients become discon- 



nected, then no synchronization can occur in real time. 
The (X)DA system is also not well suited to mobile com- 
puting because of the way it caches data and synchro- 
nizes with the CODA servers. In CODA when a server is 

5 opened, the client always tries to get the latest version 
of the file among all servers available. When the file is 
dosed the client always tries to synchronize with all 
servers available. This is extremely expensive due to 
the heavy data transmission. Moreover, CODA cannot 
10 support disconnected operation if a file access was not 
cached on the client prior to the disconnection. This is 
because in CODA the data is not replicated as a whole 
but rather the files are cached one by one. Thus the 
CODA system is complicated when trying to apply it to 

15 mobile computing as it requires parallel synchronization 
witii multiple servers with every open and close of a file. 
[0006] With respect to the Reus system, it is a file rep- 
lication system which does not support dient/server 
synchronization. It is essentially a peer-to-peer system 

20 and as such all synchronization between replication 
sites is automated. This is not economical in the mobile 
computing environment where it may not be desirable 
because of tiie expensive and unreliable nature of the 

communications links.~The Rcus-systemmay-also vio- 

25 late the semantics of an application due to the auto- 
matic synchronization, making this system not 
applicable in such cases. Since synchronization in 
Ficus is realized by using version vectors maintained by 
individual files, the version vectors need to be 

30 exchanged for each file. This is considered not efficient 
for wireless communication. For example, all the version 
vectors of files must be transmitted between senders, 
altiiough the files on both servers may be tiie same. 
Also, the Ficus system does not support differential syn- 

35 chronization because it sends whole files during the 
synchronization process in an all-or-none manner. 
[0007] Rnally, tiie Bayou system is a data base repli- 
cation system which supports differential synchroniza- 
tion by utilizing a log of writes applied to tiie database. 

40 However, the Bayou system imposes using a single pri- 
mary server to globally finalize the order and commit- 
ment of writes. A single primary server, if down, delays 
tiie final commitment of the writes. Thus if the primary 
server is down, tiie final order of the writes cannot be 

45 established. This delays tiie ability of other servers to 
see the stabilized database as soon as possible. More- 
over, tiie Bayou system requires applications to add 
conflict detection and resolution code to every write they 
generate. This requirement leads to problems. First, ttie 

50 conflict detection is not done by the system, but by tiie 
application, which can be a burden to some of the appli- 
cations. Secondly, this code for conflict detection and 
resolution must be propagated along witii each of tiie 
writes which can greatiy inaease the cost and traffic of 

55 data synchronization. 

[0008] Moreover, all of the above systems are not flex- 
ible enough to deal with different data types across dif- 
ferent systems. 
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[0009] It is therefore necessary to provide a system 
which can cope with all of the problems descrtoed 
above, especially for the mobile computing environ- 
ment. 

SUMMARY OF THE INVENTION 

[0010] In order to solve the above problems, espe- 
cially in a mobile computing environment in which links 
to either a central server or peer-to-peer system are 
oftentimes unreliable, a system is provided for reliable 
synchronization of versions of an object stored at differ- 
ent servers which involves the replacement of either the 
single central server or a peer-to-peer server system 
with a network of primary servers linked with high per- 
formance reliable links which serve to synchronize sec- 
ondary servers. The use of the primary servers permits 
the data to be distributed in a wider area with better data 
consistency arxJ more reliability because of the use of 
multiple primary servers. By making the mobile compu- 
ter a secondary server, this distinguishes these less reli- 
able senders from those servers which are the bacMx)ne 
of the synchronization process. 
[0011] In one embodiment, the primary servers are 
automatically and frequently synchronized in order to 
maintain good data consistency among the primary 
servers. On the other hand, the less reliable synchroni- 
zation from tiie secondary servers is controlled from the 
secondary servers so that communication costs can be 
reduced and so that the document or other data will not 
be synchronized unless authorized by the user at the 
secondary server. This permits the user to work with 
drafts of documents or uncompleted software or pro- 
gramming which is not to be synchronized before it is 
finished. 

[0012] As an important feature, in the subject system 
a summarizing version vector is used to minimize the 
amount of data transmitted in the synchronizing process 
by avoiding the necessity for exchanging version vec- 
tors for Individual objects, whether or not there is any 
difference In the two objects being synchronized. 
[001 3] The term summarizing version vector as used 
herein means a vector having fields which summarize 
the state of the object container at a server. Each sum- 
marizing version vector is a vector of update stamps. 
Each update stamp has a field for the associated object 
container's identifier and a field for the associated time 
stamp. 

[001 4] In the case that the objects are not the same, 
in the prior art, version vectors for each object at a first 
location were sent to a second location, witii a corre- 
sponding update being sent back to the first location. 
This created an a situation in which needless data was 
transmitted. 

[0015] In the subject system a single summarizing 
. version vector is sent from a first location to a second 
location, and all the updates are then returned all at 
once to the first location. In one embodiment, the sum- 



marizing version vector is examined at the second loca- 
tion to determine if a whole object or a portion of the 
object needs to be sent to the first location. This is 
accomplished by either defining a version vector to a 
5 ^ whole object or defining a version vector to the t^ase of 
an object and the update stamp for each of its differen- 
tial updates. 

[0016] As used herein the base of an ot}ject refers to 
an ok^ject in its initial form absent any changes reflected 

10 by differential updates. 

[0017] Next the received summarizing version vector 
is compared with either the above version vectors of the 
individual objects or the update stannps for individual dif- 
ferential updates. As noted above, the update stamp of 

IS a differential update consists of the identifier of the 
object container v^ich generated it and the time stamp 
when it was generated. 

[0018] All of the whole objects or differential updates 
are only sent to the first location if their version vectors 

20 or updated time stanps are eitiier newer than the 
received summarizing version vector or conflicts with it, 
tiius eliminating the unnecessary version vector transfer 
associated with prior art systems. Thus tiie summariz- 
ing version vector system eliminates repeated transfer 

25 of version vectors associated with IndividuaL objects. 
[001 9] Another use for tiie summarizing version vector 
is as follows. It will be noted that in tiie past, synchroni- 
zation systems have operated on an all or nothing basis, 
meaning tiiat if the synchronization fails before comple- 

30 tion. then all of tiie data must be present. In the subject 
In the subject system, when an update is sent from a 
first server to a second server, lx>th the version vector of 
the corresponding object and the summarizing version 
vector in the second sever will be updated right after it 

35 successfully receives the iqxiate. Therefore, when syn- 
chronization falls, the synchronization will be restored 
without resending tiie updates which were already 
received by the second server in the previous synchro- 
nization by conparing the first server's summarizing 

40 version vector witii the second server's updated version 
vector. This offers more fine grain synchronization and 
Is therefore more f^ult tolerant. Thte is because in the 
subject system tiie unit of transmitted data may be a dif- 
ferential update, called an atom because of its small 

45 size. This is distinguished from the prior art systems 
which must transmit the whole object as the unit of 
transmitted data. If more than two servers are involved, 
tiie synchronization may be restored t>etween the first 
server and tiie second server after tiie point of failure if 

so in the meantime a third server has synchronized witii 
ttie second server between the time of tiie feiilure and 
tiie time of the restart. The above is made possible by 
tiie use of the summarizing version vector. 
[0020] It will be appreciated that the object in a con- 

55 tainer may be any object, for instance a document a 
program, or a row of a table in a relational database, 
making the subject system a universal system. This 
integrates the synchronization process for various forms 
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of data and is made possible by the separation of the 
senfiantics of objects from the synchronization. This is in 
contrast to existing systems which are dependent on 
the form of the data. 

[0021] As one important aspect of the subject inven- 
tion, the subject system permits synchronization 
between different systems such as synchronizing 
between a Word document a McDraw document and a 
FrameMaker document because the semantics of the 
data may be separated from the synchronizing. This is 
accomplished by extracting updates in a standard for- 
mat and synchronizing based on the standard protocol. 
[0022] In operation, an update at one location in one 
format is converted to an update in the standard proto- 
col. The update in the standard protocol is transmitted 
to a second location where it is converted to the format 
of the object at the second location. 
[0023] Moreover, the subject system uses drfferential 
synchronization to minimize the data transfer to only 
that data which is changed between versions of objects. 
As a special feature of the subject invention, the system 
switches from whole object synchronization to differen- 
tial synchronization when, for instance, local memory is 
JuILqt when_disc spa ce is limite d . Additiona lly when jn^ 
object at one location is very old, if differential synchTo^ 
nization is being used, it is convenient to update the 
entire or whole object at this second location by auto- 
matically shifting to whole object synchronization. 
[0024] It is a further feature of the subject invention 
that synchronization from a mobile computer can be 
done either in the client/server mode from secondary 
server to primary server, or can be done amongst the 
secondary servers, either peer-to-peer or in a hierarchi- 
cal system, thus permitting mobile-to-mobile synchroni- 
zation. For example, if one secondary server is a user's 
desktop computer and another secondary server is a 
mobile device for secondary use. then data synchroni- 
zation between the two secondary servers is of a client- 
server type, while the data synchronization of two 
mobile devices for instance owned by two salesmen for 
exchanging each other's sales data is of the peer-to- 
peer type. As a result of the fact that the subject system 
supports both peer-to-peer and hierarchical structures, 
the subject system will support any topology of the sec- 
ondary servers. 

[0025] Because oftentimes a server is only concerned 
with data from a selected number of servers, it is unnec- 
essary to synchronize with all of the servers in the sys- 
tem. In a system which has a large number of servers, 
only some of which have data which one wishes to syn- 
chronize, if one were to attempt to keep track of alt 
objects and all updates, memory would be quickly 
exhausted. 

[0026] In order to solve this problem in one embodi- 
ment of the subject invention, a latest common ancestor 
version vector is utilized to selectively purge updates 
and version changes at a selected group of servers 
which are oMer than or equal to this latest common 
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ancestor version vector by purging off differential 
updates or deleted otsjects which have propagated to 
the group of the servers in question, e.g. the selected 
servers. 

5 [0027] Ideally, a server should purge off differential 
updates or deleted objects only if all of the servers in a 
system have received the updates. However, because 
the number of servers, especially the secondary serv- 
ers, dynamically changes, and some servers may be 
10 disconnected from the whole system for a very long 
time, purging off updates only after all the servers 
received them is impractical and the memory or disk 
space may be exhausted even before it can actually 
purge off updates. 
15 [0028] Therefore, in the subject system, the system 
allows a server to select a set of servers and purge off 
updates if the updates have already propagated to all of 
the selected servers. 

[0029] Furthermore, a selected server may also be 
excluded in the consideration of purging off of updates if 
it is not synchronized with the selecting server for a time 
period in excess of a pre-set limit. 
[0030] In the subject system, this purging off of 
updates is done by utilizing the latest common ancestor 
version vector. When a server synchTonlzeslvith~any^^ 
the selected senders, it will record the selected servers 
versions vector locally The latest common ancestor ver- 
sion vector is then calculated from its own version vec- 
tor and all of the selected server's version vector. Any 
differential updates or deleted objects' information will 
be purged off if their update stamps or version vectors 
are newer than or equal to the calculated latest common 
version vector. 

the synchronization algorithm as shown below uses 
both summarizing version vectors and update stamps to 
minimize the data transmitted. During synchronization, 
the subject algorithm goes through the below listed 
steps in order to realize the propagation of updates from 
one server to another: 

1) The first server sends its summarizing version 
vector to the second server. 

2) Upon receiving the summarizing version vector 
of the first server, the second server sends to the 
first server its summarizing version vector, followed 
by all of the identifiers of objects which exist in the 
second server and that can support differential syn- 
chronization. 

3) Upon receiving the summarizing version vector 
and identifiers from the second server, the first 
server figures out all of identifiers of objects which 
need to be received as whole objects and sent to 
the second server. The sub-steps for this step are 
as follows: 

a) Find out all objects which exist in the second 
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server but do not exist in the first sender and put 
their identifiers into the list of objects needed to 
be received from the second server. This is 
done by checking if any of the received identifi- 
ers of objects matches the identifier of any 5 
object existing in the first server. 

b) Rnd out all objects which exist in lx)th serv- 
ers that can support differential synchroniza- 
tion. Then check if any newer than the common 10 
version vector of the two servers, where base 
version vector of an object refers to the version 
vector of the object absent any differential 
updates and where the common version vector 
refers to a version vector reflecting the state is 
from where the two servers' summarizing ver- 
sion vectors diverged. All of the identifiers of 
the objects which passed the check are also 
added to the list of objects needed to be 
received from the second server. 20 

c) Send all the identifiers obtained from sub- 
steps a) and b) to the second server. 

4) Upon receiving the identifiers from its first server, 25 
the second sender compares its latest common 
ancestor version vector with the summarizing ver- 
sion vector of the first server. If the summarizing 
version vector of the first server is older than the 
second server's latest common ancestor version so 
vector, it extracts all the individual whole objects it 
contains. OthenAnse, it proceeds to compare its 
summarizing version vector with the first server's 
summarizing version vector. If the second server's 
summarizing version vector is newer than the first 35 
server's summarizing version vector, the second 
server wilt scan all the objects existing in it. If the 
identifier of an object appears in the list of identifiers 
received from the first server, it is sent to the first 
server as a whole. If an object is the one needed to 40 
be sent as a whole because it does not support dif- 
ferential synchronization and its version vector is 
either newer or conflicting with the first server's 
summarizing version vector, this object will also be 
sent to the first sender. If an object is the one which 4S 
supports differential synchronization and its base 
version vector is newer than the first server's sum- 
marizing version vector, this object will be sent to 
the first server as a whole too. Rnally, if an object is 
the object which supports differential synchronize- so 
tion and has updates which stamps are either 
newer than or conflicting with the first server's sum- 
marizing version vector, these updates will be sent 
to the first server as the differential updates. The 
order of all of the objects or updates being sent is ss 
determined first by the ordering of version vectors 
or the associated update stamps. If there is a dis- 
crepancy in the ordering, then a secorxlary order- 



ing process is invoked. 

5) After finishing step 4, if the first servier is one of 
the second server's selected servers, the second 
server will store or update the first server's summa- 
rizing version vector it has stored previously It m£^ 
also recalculate its latest common ancestor version 
vector if all of the selected servers' summarizing 
version vectors have been stored in the second 
server, and accordingly purges off all the deleted 
object's information or differential updates whose 
version vectors or update stamps are older than or 
equal to the latest common ancestor version vector. 

6) Upon receiving each object and update from the 
second server, the first server updates the informa- 
tion in it as follows: 

a) If the received object or update has a version 
vector or time stamp older than or equal to the 
version vector of the conesponding object in 
the first sender, this object or update will be 
thrown away 

b) If a whole object was received and its ver- 
sion vector is newer than the version vector of 
the corresponding object in the first server, the 
object in the first server will be replaced with 
the received object, and accordingly the 
object's version vector and the first server's 
summarizing version vector will also be 
updated. 

c) If a whole object was received and its version 
vector is conflicting with the version vector of 
the corresponding object in the first server, the 
two versions of the object will be reconciled by 
calling a reconcile method on the object in the 
first server, with the received object as the 
argument. As the result a new object will be 
generated to replace the object in the first 
server, and accordingly, a new verston vector 
for the new object is generated and the sum- 
marizing version vector of the first server is 
updated. 

d) If a differential update was received and its 
update stamp and the received second server's 
summarizing version vector indicate it is not yet 
contained in and was generated after the conre- 
sponding object's differential updates in the 
first server, the received updates will be added 
to the top of the object's differential updates in 
the first server. Accordingly, the summarizing 
version vector of the first server will be 
updated. 

e) If a differential update was received and its 
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update stamp and the received second server's 
sunrunarizing version vector indicate it is not yet 
contained in and was not generated after the 
con-esponding object's differential updates in 
the first server, the differential update(s) in the 
first server that were generated after the com- 
mon state of the two servers will be extracted, 
and both the extracted differential updates and 
the received differential update will be passed 
as arguments to the reconcile method on the 
object in the first sender in order to reconcile the 
conflict between them. As a result, the object in 
the first server will be replaced with a new 
object or a new update will be added to the 
object's differential updates in the first server, 
and accordingly a new version vector for the 
new object or the update stamp for the new 
update will be generated and the summarizing 
version vector of the first server will be 
updated. 

7) After finishing step 6, if the second server is one 
of the first server's selected servers, the first server 
will store or update t h e second se rver's s ummariz- 



[0031 ] As can be seen from the description above, the 
subject algorithm has two advantages compared with 
the existing algorithms. Rrst, it can avoid transmitting 
per-object version vectors from one server to another. 
Secondly it can transmit the differential updates which 
are incorporated in one server, but not incorporated in 
another server. An additional advantage of the subject 
algorithm is that it offers finer grained synchronization, 
and is more fault-tolerant. 

[0032] In summary, a universal system is provided for 
synchronizing servers which accommodates wide area 
mobile computing while at the same time making the 
synchronizing process more efficient. First, the intro- 
duction of multiple primary sen/ers with high perform- 
ance reliable links ensures high data availability and 
scaleability. Secondly, the introduction of the secondary 
servers makes the subject system well suited for mobile 
computing which may use unreliable and expensive 
links. Moreover, with the control of the synchronization 
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ing version vector it has stored previously. It may 25 
also recalculate its latest common ancestor version 
vector if all of the selected servers' summarizing 
version vectors have been stored in the first server, 
and accordingly purges off all the deleted object's 
information or differential updates whose version so 
vectors or update stamps are older than or equal to 
the latest common ancestor version vector. 

8) After finishing step 7, the update propagation 
from the second server to the first server is com- 35 
pleted. If a two way update propagation is required 
then steps 1) to 7} can be repeated by replacing the 
first server with the second server and vice versa. 
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by secondary senders, economical synchronization can 
be achieved. Further, since some applications do not 
permit automatic synchronization, user control of syn- 
chronization which prevents unintended synchroniza- 
tion Is critical. 

[0033] A second aspect of the subject invention is the 
use of a summarizing version vector. This summarizing 
version vector is used to minimize the amount of data 
transmitted in the synchronization process by avoiding 
the necessity for exchanging version vectors for individ- 
ual otsjects. It can also further reduce data to be trans- 
mitted by working with update stamps associated with 
individual differential updates to permit differential syn- 
chronization. A latest common version vector can be 
constructed from a server's summarizing version vector 
and the summarizing version vectors of a set of its 
selected servers, which is used to reduce differential 
updates on the server. Additionally, the summarizing 
version vector permits the re-start of synchronization 
from the point of previous failure with data from an unaf- 
fected server. It also supports fine grain synchronization 
by permitting a differential update as the atom of data to 
be transmitted. 

_[Q034]_ As a.significant feature.of.the.subject invention: 
the system will switch between whole object synchroni- 
zation and differential synchronization automatically 
For instance in memory management It is oftentimes 
desirable to switch from differential synchronization to 
whole object synchronization due to the memory inten- 
sive nature of differential processing. Also when doing 
whole object synchronization It may be beneficial to 
switch to differential synchronization to minimize the 
data to be transmitted. 

[0035] Last but not least, the subject system permits 
a synchronization between different systems because 
the semantics of the data Is separated from the syn- 
chronization, making the system universal as to the for- 
mat of the data. 



40 BRIEF DESCRIPTION Q F THE DRAWINGS 



[0036] These and other features of the subject inven- 
tion will be better understood with reference to the 
Detailed Description taken in conjunction with the Draw- 
ings, of which: 



Figure 1 is a diagrammatic representation of the 
system architecture of the subject inven- 
tion illustrating the primary server/second- 
ary server structure; 

Figure 2 is a diagrammatic representation of the 
architecture of the server for the system of 
Figure 1 showing an object container 
manager, a synchronization manager, 
synchronizers and object containers; 

Figure 3 is a diagrammatic representation of the 
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major subroutines for each of the compo- 
nents shown in Figure 2; 

Figure 4 is a block diagram of the structure of the 
object container of Figure 2, showing the 
summarizing version vector used therein, 
the latest common ancestor version vec- 
tor and the structure of the differential 
based log used in the subject system; 

Figure 5 is a diagrammatic representation of the 
synchronization of two servers illustrating 
the utilization of summarizing version vec- 
tors; 

Figure 6 is a block diagram illustrating a process for 
modifying objects in an object container; 

Figure 7 is a diagrammatic representation of a syn- 
chronization protocol showing the 
exchange of data between first and sec- 
ond servers; 

Figured is a block diagram of the system for 
extracting updates to be transmitted from 
a first server to a second server utilizing 
summarizing version vectors and a differ- 
ential update tog for the second server; 

Figure 9 Is a block diagram showing a process for 
detecting and resolving conflicts between 
two servers; 

Figure 10 is a block diagram showing a process for 
the purging off of update logs at a server; 
and, 

Figure 11 is a block diagram illustrating the switch- 
ing of the synchronization system from a 
whole object synchronization process to a 
differential synchronization process based 
on predetermined characteristics of the 
system. 

DETAILED DESCRIPTION 

[0037] Referring now to Figure 1 , the system architec- 
ture involving primary and secondary servers is illus- 
trated. Here a network 10 of primary servers 12 is 
interconnected through the utilization of high perform- 
ance links 14 which are generally orders of magnitude 
more reliable than wireless links. It is the purpose of the 
high performance links to ensure synchronization integ- 
rity and to permit connection of secondary servers to 
the primary servers. 

[0038] As illustrated, a number of secondary servers 
16 are either linked to each other as illustrated at 18 in 
a peer-toi^eer relationship; or are linked as illustrated at 



12 

20 In a hierarchical manner. As discussed hereinbefore, 
it is this primary server/secondary server architecture 
which permits reliable synchronization with virtually any 
type of system, be it a peer-to-peer system or a hierar- 

5 chical system. It will be appreciated that because of the 
primary server/secondary server architecture, any type 
of system can be accomnxxJated, thus the subject sys- 
tem can accommodate any topology amongst the sec- 
ondary servers. 

10 [0039] Referring now to Figure 2, in one enlbodiment, 
the architecture of the server of the subject system 
includes a number of object containers 22 and an object 
container manager 24 coupled tiiereto. The object con- 
tainer manager is coupled to a synchronizer manager 

IS 26 which Is In turn coupled to object containers 22 and 
synchronizers 28. A protocol utility 30 is driven by syn- 
chronizer manager to select the most reliable connec- 
tion to the network 

[0040] In operation, a system utility or application ini- 

20 tiates synchronization from either the object container 
or the synchronizer manager. Synchronizer manager 26 
consults with utility 30 to open a reliable connection 
between two servers to be synchronized. Thereafter, 
synchronizer manger 26 creates a synchronizer such as 

25 synchronizer 28 based on the result from the protocol * 
utility. Then the synchronizers on the two servers will ini- 
tiate the synchronization process. 
[0041] Referring now to Figure 3. tiie subroutines or 
methods utilized in the system of Figure 2 are now 

30 described. It will be appreciated that object container 22 
utilizes a put method 32 a delete method 34, a get 
metiiod 36. a synchronize method 38. an applyllpdate 
method 40. a generateUpdates method 42. a purgeOff- 
History method 44 and a getSummarizingVersionVector 

35 46. These methods are written in Java and can be found 
in the source code hereinafter. 
[0042] As can be seen, object container manager 24 
is provided with an openObjectContainer method 50, 
whereas synshronizer 28 is provided with start method 

40 52, pull method 54, push method 56 and stop method . 
58, all written In Java and can be found in the source 
code hereinafter. 

[0043] Synchronizer manager 26 is provided w'rth a 
synchronizermethod 60. whereas protocol utility 30 is 

45 provided with an isConnected method 62 and a get- 
BestConnectlon metiiod 64 which are standard. 
[0044] Referring now to Figure 4. tiie data structure of 
the subject system is shown for use witii object con- 
tainer 22. Of importance is tiie structure of the summa- 

50 rizing version vector, here illustrated at 70 which is used 
throughout the subject invention. As can be seen, the 
summarizing version vector of object container 22 has a 
field for identification 72 and a field for a time stamp 74. 
It will be appredated tiiat Sid^ refers to ot^ject container 

55 1 in the system, whereas the number 1 544 refers to a 
time stamp associated with object container 1. The 
summarizing version vector In essence contains the 
identifiers and the time stamps for all of tiie objects in 
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the respective containers. As shown at 80. a similar 
summarizing version vector for a remote object con- 
tainer is shown at 76. It will thus be appreciated that 
there are summarizing version vectors at a number of 
locations throughout the system. 5 
[0045] As illustrated at 80 there is a specialized ver- 
sion vector called the latest common ancestor version 
vector which serves to identify that differential updates 
which can t>e read off of the object container because a 
set of remote object containers predefined or prese- io 
lected containers which already have received common 
differential updates. This permits purging off of certain 
updates because they are already stored in the prede- 
fined set of object containers. 

[0046] As illustrated at 82. a log structure is shown is 
which contains the history of updates to the object con- 
tainer 22. As can be seen, the log contains a field 84 
having a reference to either the object version vector 86 
or to the update stamps 88. and a field 90 having a ref- 
erence to the corresponding object 92 or differential 20 
update 94. It will be appreciated that object 96 associ- 
ated with update 94 contains an additional update 98, 
both of which have updated the initial object, here illus- 
trated as base 100. 



[0047] Object 92 is the object which must always be 25 
sent as a whole object, whereas Object 96 can be in 
terms of differential updates to a base. 
[0048] Referring now to Figure 5, what is shown is a 
system to permit the change of data In the object con- 
tainer during synchronization. As can be seen, an 30 
object container 1. here illustrated at 112 is provided 
with summarizing version vector of server 1 as 
illustrated at 1 1 1 Also provided to object container 110 
are summarizing version vectors OW^ . of servers other 
than server 1, here illustrated at 1 14. The latest com- 35 
mon ancestor version vector, CW^ of server 1 as illus- 
trated at 1 16 is also supplied to object container 1 10. 
Likewise, update log 1 of server 1 as illustrated at 1 18 is 
also applied to object container 110. 
[0049] Object container 1 1 0' illustrates a dynamically 40 
changing state for object container 1 10 having the indi- 
cated inputs, 1 12*-118'. The dynamically changing state 
of object container 1 1 0 occurs as a result of object con- 
tainer 120 having been dynamically changed as illus- 
trated at 120' which sends data to object container 110 4s 
as illustrated by arrow 1 20. It will be appreciated that the 
synchronization process starts by object container 110 
sending summarizing version vector 1 as illustrated at 
arrow 122 to the server associated with object container 
2, here illustrated at 120. Object container 120 Is so 
changed so that it contains synchronizing information 
supplied by summarizing version vector 1 so that it in 
turn updates object container 110 throughout informa- 
tion sent as illustrated by arrow 124. 
[0050] As will be appreciated, object container 120 ss 
has as inputs the summarizing version vector W2 of 
server 2 illustrated at 126, the summarizing version vec- 
tors of 0 W2 of servers other than server 2 as illustrated 



at 128. the latest version vector of CW2 of server 2 as 
illustrated at 130 an update log 2 of server 2 as illus- 
trated at 132. 

[0051] The information sent, as illustrated by arrow 
122, is the summarizing version vector 2. plus identifier 
of objects in object container 120 which support differ- 
ential synchronization. 

[0052] The synchronization continues as illustrated by 
an-ow 134, witii information going from object container 
1 10* to object container 120". The information transmit- 
ted as illustrated by an^ow 134 are identifiers of objects 
which supports differential synchronization absent tiie 
objects of container 1 , but which objects exist in object 
container 2. This can be ascertained by comparing tiie 
received identifiers of objects from object container 120* 
as illustrated by arrow 1 24 with ttie identifiers of objects 
in object container 1 . Note that the summarizing version 
vector Is not sent at this point because it has been pre- 
viously sent in the first stage of the synchronization 
process. 

[0053] With the transmission of information as illus- 
trated by an-ow 124, it is possible for object container 
120" to be purged off information which is stale. The 
pur ging off of historically stale information is accom- 



plished by access to the latest common version vector 
CW2\ here illusti^ated at 130*. 
[0054] Thereafter, updates are sent from object con- 
tainer 120" to object container 110" at which point, a 
purging operation can take place. After ail of the purging 
operations take place, the synchronization is completed 
such tiiat okDject container 110*" will contain the most 
updated version of all of the objects in the system. It will 
be appreciated ttiat tiie objects in object container 120 
can be synchronized and updated in the same manner. 
[0055] Referring now to Figure 6, what is illustrated is 
a system for modifying an object in an object container. 
Here, an object container 1 40 is supplied witii a summa- 
rizing version vector 142 and an update log 144. The 
modification step, as illustrated at 146. requires tiie 
input of a different summarizing version vector, here 
illustrated at 148. along witii its associated update log, 
here illustrated at 150. What this diagram illustrates Is 
tiiat if an object container 140 is modified, tiien it is nec- 
essary to modify the corresponding summarizing ver- 
sion vector and its corresponding update log in order to 
record a modification. 

[0056] Referring now to Figure 7. what is illustrated is 
a synchronization protocol. The synchronization proto- 
col involves two synchronizers with one as the synchro- 
nization Initiator and another as a synchronization 
responder. The synchronizer initiating the synchroniza- 
tion first sends a pull/push request to the synchroniza- 
tion responding to tiie synchronization which is ready to 
listen to the synchronization initiator. Thereafter, this 
responding server sends a summarizing version vector 
back. Then a furtfier summarizing version vector is 
transmitted in tiie opposite direction along with identifi- 
ers of objects which support differential synchroniza- 
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tion. Next, identifiers of objects are sent back in the 
opposite direction coming with the result being the 
sending and update to the server responding to the ini- 
tial synchronization request. 

[0057] The result of the synchronization protocol is 
that the server initiating the synchronization is provided 
with an update corresponding to the latest common 
ancestor version vector, with ail differential updates 
purged off. The same is true for the sender responding 
to the synchronization request. 
[0058] Refening now to Figure 8. what is described is 
a method for extracting updates to be transmitted. Here, 
a server 160 has an associated summarizing version 
vector 162 which contains the aforementioned fields 72 
and 74. The highlighted field indicates a time stamp 
which is earlier in time than the corresponding value in 
the summarizing version vector of a second server, 
server 164. This is illustrated by highlighted portion 166 
of summarizing version vector 168 associated with 
server 164. 

[0059] The updates are extracted by checking the ver- 
sion vectors or update stamps in the update log 170 of 
server 164. Note these version vectors or update 
stamps are the ones found at 86 in Figure 4. The check- 
ing process is accomplished in one embodiment as fol- 
lows: Any object or differential update with a version 
vector or update stamp that includes at least one time 
stamp greater than the highlighted corresponding time 
stamp in summarizing version vector 162 and less than 
or equcd to the highlighted corresponding time stamp in 
summarizing version vector 168 is extracted. 
[0060] Referring to Figure 9, a method for detecting 
and resolving conflicts is shown in which a server 180 
has a corresponding summarizing version vector . An 
update log 184 is coupled to server 180 and contains an 
object 186 which contains three differential updates 
188, 190 and 192 on top of its base 194. As to the sec- 
ond server, server 196, this server is provided with a 
summarizing version vector 198 and a con'esponding 
update log 200, server 196 contains an object 202 
which is the same as object 186. with the exception that 
it has different differential updates indicating a conflict 
with 186. This is shown by comparing the highlighted 
portions 204 and 206 with highlighted portion 188. The 
problem is how to figure out why updates 204 and 206 
are in conflict with update 186. This conflict detection is 
accomplished by comparing the version vectors or 
update stamps of the whole object, not shown in this fig- 
ure, or the differential updates 188. 190. 192 in the 
server 180 and the differential updates 204, 206. 208, 
210 in server 196 with the common version vector 212 
of the summarizing version vector 182 and 198. The 
common version vector of the two summarizing version 
vectors reflects a common state for the two servers. If 
there are differential update(s) of objects 186 and 202 in 
both the servers 180 and 196 that have a time stamp 
greater than the corresponding time stamp in the com- 
mon version vector 212, then two objects 186 and 202 



are in conflict. 

[0061 ] After the objects 1 86 and 202 have been found 
to be in conflict, the conflict Is resolved or reconciled by 
calling a predetermined reconcile method and passing 

5 the differential updates in conflict to the method as 
shown at 220. It will be noted that the reconcile method 
is usually determined t>ased on a specific application. 
[0062] Referring now to Figure 10, one method of a 
purging off update logs is shown. Here, a server 260 

10 has a summarizing version vector of itself, illustrated at 
260, and the summarizing version vectors 262 and 260 
from other servers. The latest common version vector 
266 of the server 230 is calculated from all the three 
summarizing version vectors 230, 232. and 234 which 

IS represents the common state of all three servers. Hav- 
ing obtained the latest common version vector 236, it is 
possible to purge off the con^esponding update log 
entries in the update log 238. This means that log 
entries bracketed by bracket 240 may be deleted or 

20 purged. This is because these updates have an update 
stamp which is older than the latest common version 
vector 236, reflecting the fact that these updates have 
already been incorporated in all the above three serv- 
ers. 

25 [0063] Refenring now to Figure 11, it is possible to 
switch between whole object synchronization and differ- 
ential synchronization. Here, whole object synchroniza- 
tion is shown at 150, whereas differential 
synchronization is shown at 162. A switch 254 is used to 

30 determine which synchronization process will be used. 
Switch 254 is under the control of logic 256 which oper- 
ates as follows. 

[0064] In one embodiment, whether an object which 
can support differential synchronization will be synchro- 

35 nized by sending it as a whole object or the portion of its 
differential updates is determined by the following logic:^ 
First, if the object only exists in a first server and is 
ak)sent from a second server, then the whole object 
needs to be sent from the first server to the second 

40 server when the two senders synchronize with each 
other. Secondly, if the object exists in the two servers 
and if at least at one server the state of the t>ase of the 
object is newer than the common state of the object at 
the two servers, then no differential synchronization on 

45 the object can be done between the two servers 
because the object at either of the two servers can not 
be synchronized up-to-date after receiving only differen- 
tial updates from the other server. This requires switch- 
ing to whole object synchronization. Otherwise. 

50 differential updates can be realized between the two 
servers, and tiie system can be switched to differential 
synchronization. 

[0065] Other factors, if needed, can be added to the 
logic for tiie switch between whole object synchroniza- 
55 tion and differential synchronization. For instance, a 
switch from differential synchronization to whole object 
synchronization may be triggered if the free space of 
memory is dose to being exhausted, or if it Is fbund to 
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be more efficient to send a whole object other than Its 
differential updates. Altematively. a switch from whole 
object synchronization to differential synchronization 
can be determined to minimize the data to be transmit- 
ted. In other words, it may be desirable to switch to dif- 
ferential synchronization when it is more efficient to 
send an object's differential updates as opposed to the 
whole object Note that the switch between whole object 
synchronization and differential synchronization is 
determined on the basis of individual objects. 
[0066] More particularly, the data in the subject sys- 
tem can be files, documents, databases or the mix of 
part or all of these and they will be appropriately ground. 
The way data are grouped can change from application 
tP application. For example, in file systems, a directory 
can be considered as a file group and it may further 
define structures inside to organize data (files). In object 
oriented databases, a data group possibly includes all 
the homogeneous or heterogeneous objects needed to 
meaningfully support its applications. As the first step, 
we assume that all the data groups in different devices, 
which need to be synchronized with each otiier. eventu- 
ally contain exactly the same data set 
_^[P067]_JJe_syaject^ystern^ 
using Java. Therefore, all descriptions below are based 25 
on Java's terminology. An object container is a container 
which stores and maintains a Java object group. 
Objects in the object container are represented by Syn- 
chronizable objects which are any Java Seriatizable 
objects providing a replace/apply metiiod and a 30 
reconcile mettiod. SynchronizaWe objects are the 
abstraction of concrete data such as files, documents, 
or rows of database tables. Assuming that a full set of 
(Synchranizable) objects already exist In an object con- 
tainer, applications can tfien access objects in the 35 
object container by calling its get or put methods. 
[0068] In a sender, multiple object containers can be 
created by calling the object container manager's 
openObJectContainer method. In each server, only one 
object container manager can exist and is used to man- 40 
age all the object containers at the server. In addition to 
creating object containers, rt also offers services such 
as listing or deleting the created object containers. For 
convenience, each c^ecX container will be assigned a 
globally unique identifier when created which can be 45 
used when referencing that object container in ttie sub- 
ject system. In one embodiment tiie object container 
identifiers can be assigned to tiie hash codes which are 
generated by a one-way hash function witti the URLs of 
the object containers as ihe input to it. 50 
[0069] Synchronizers are tiie key component in the 
subject system in order to bring any two object contain- 
ers into a consistent state. There can be multiple syn- 
chronizers In each server, where each of the 
synchronizers uses a different type of communications ss 
transport and protocol. For example, synchronizer 1 
may use TCP/IP and a two-way synchronization proto- 
col while synchronizer 2 may use infrared and a one- 



way protocol which is more suited for unreliable wireless 
communications. A synchronizer Is dynamically aeated 
by the synchronizer manager when needed and will be 
self-desti-oyed just after it has finished the synchroniza- 
tion. The synchronizer manager in a server can either 
bind an object container which is going to be synchro- 
nized with a synchronizer and trig tiie synchronizer to 
start the synchronization, or listen to one or more syn- 
chronization requests from tiie synchronizer managers 
at remote servers. The protocol utility can help the syn- 
chronizer manager adaptively select a synchronizer to 
be generated tiiat matches the best connection availa- 
ble currently. The protocol utility is one of the classes 
provided by tiie Java extension package. 
[0070] As can be seen from tiie above description, tiie 
object semantics, such the format It uses to represent 
its contents and the algorithms it uses to reconcile con- 
current update conflicts, is separated from the synchro- 
nizer. This feature leads to tiie ability tiiat tiie subject 
system may synchronize between different application 
systems. 

[0071] Assume server 1 is specified to synchronize 
tiie object container 1 at it witii the object container 2 at 
Jhe seivejJURjrthe^ 

died to object container 1 (1 = 1 ,2) are annotated as syn- 
chronizer manager 1, synchronizer i. etc. The detailed 
steps for tiie whole synchronization process are as fol- 
lows: 

1) Synchronizer manager t opens a communica- 
tion channel to the synchronizer manager 2 which 
has been listening to synchronization requests. 

2) Synchronizer manager 1 sends the synchroniza- 
tion request to synchronizer manager 2 which indi- 
cates tiie object container to be synchronized with 
and tiie synchronizer to be used In tiie synchroniza- 
tion. 

3) Synchronizer manager 1 and 2 create and con- 
nect the pair of matching synchronizers 1 and 2 
with synchronizer 1 as the synchronization initiator 
and synchronizer 2 as the listener. 

4) Synchronizer 1 sends a pull or push update com- 
mand to synchronizer 2. The pull update command 
means tiiat object container 1 requires tiie receipt 
of updates from object container 2, whereas the 
push update command means tiiat object container 
1 will propagate updates from it to object container 
2. Whetiier synchronizer 1 should send the pull or 
push update command or botii in a serialized man- 
ner Is determined by tiie system utility or application 
which Initiated the synchronization. The following 
steps assume tiiat synchronizer 1 sent a push 
update command to synchronizer 2. When syn- 
chronizer 1 has sent a pull update command to syn- 
chronizer 2, synchronizer 2 sends a confirmation 
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message back to synchronizer 1 and the rest of the updates to object container 1 by calling the apply* 

steps will be the mirror image of the foregoing Update method as shown in Rgure 3 on object con- 

steps, tainerl. 



5) Synchronizer 1 obtains the summarize version s 
vector off object container 1 by calling the getSum- 
marizingVersionVector method as shown in Figure 
3 on object container 1 , and sends the summarizing 
version vector to synchronizer 2. The summarizing 
version vector of object container 1 reflects the cur- io 
rent state of object container 1 . 

6} Synchronizer 2, when needed, records the 
received summarizing version vector of ofc^ect con- 
tainer 1 in object container 2. Synchronizer 2 then is 
obtains the summarizing version vector of object 
container 2 and the identifiers of objects in object 
container 2 that support differential synchronization 
by calling the getSummarizingVersionvector 
method which is shown in Figure 3 and by calling 20 
the entries method described in the source code 
presented hereinafter on object container 2. The 
summarizing version vector of object container 2 
reflects the cun^ent state of object container 2. Syn- 
chronizer 2 then sends the summarizing version ss 
vector and identifiers obtained above to synchro- 
nizer 1. 

7) Synchronizer 1, when needed, records the 
received summarizing version vector of object con- 30 
tainer 2 in ot^ect container 1. Synchronizer 1 then 
obtains the identifiers of the objects which have to 

be received as a whole oljject by calling the get- 
WholeObjectlds method described in the source 
code presented hereinafter on object container 1 35 
with the received summarizing version vector of 
object container 2 and the received identifiers as 
the arguments. The identifiers obtained above 
include the identifiers of objects which exist in 
object container 2 but miss from ot)ject container 1 40 
and the objects the state of the base of which are 
newer than the common state of object container 1 
and object container 2. Synchronizer 1 then sends 
the identifiers obtained above to synchronizer 2. 

46 

8) Synchronizer 2 obtains the updates which have 
to be sent to ot>|ect container 1 by calling the gener- 
ateUpdates method as shown in Figure 3 on object 
cont£uner 2 with the received identifiers of objects 
and the summarizing version vector of object con- so 
tainer 1 received in step 6 as arguments. Each of 
the updates obtained above may be a wtiole object 
with its version vector or a differential update with 

its update stamp. Synchronizer 2 then sends the 
updates obtained above to synchronizer 1 one by ss 
one. 

9) Synchronizer 1 applies each of the received 



10) After finishing the sending or receiving updates, 
both synchronizers 1 and 2 may call the purgeOff- 
History method as shown in Rgure 3 on object con- 
tainer 1 and object container 2. respectively, in 
order to purge off the differential updates which 
have been contained in all the object containers 
object container 1 or ot^ect container 2 is con- 
cerned with. 

[0072] The applyUpdate method of an object con- 
tainer will further call one of the methods defined in an 
object in order to replace an object with the received 
object, reconcile between an object with the received 
object, add the received differential update to an object, 
or reconcile the received differential update with the dif- 
ferential update(s) of an object which are in conflict with 
the received differential update. It will also update the 
summarizing version vector of the object container to 
reflect the fact that the object container has already 
placed the update into it. 

[0073] As can be seen from the description above. 
The summarizing version vector deployed in the subject 
system is not only used for the detection of concurrent 
update conflicts, but also for reducing the number of 
entries in an update log. 

[0074] The summarizing version vector of an object 
container is in effect the summary of the version vectors 
of all the objects and the update stamps of all the differ- 
ential updates in the object container. For an object 
which cannot support differential synchronization, the 
version vector of the object reflects the current state of 
the whole object, whereas for an object which can sup-' 
port differential synchronization, the version vector of 
the object reflects the current state of the t»ase of the 
object, absent all the differential updates associated 
with it. Much like the version vector for a whole object, 
the version vector for the base of an object also dynam- 
ically changes as part or all of the differential updates 
associated with it are purged off. Therefore, the version 
vector of an object characterizes the current state of the 
whole object or the base off the object. 
[0075] The summarizing version vector of an object 
container or the version vector of an object is the vector 
of update stamps. An update stamp in turn consists of 
two fields: the first field is the identifier of an object con- 
tainer which has made modification(s) to an object if this 
is the version vector of the object or to ot)ject(s) in an 
object container if this is the sunrunarizing versbn vector 
of the object container; the second field is the time 
stamp generated by the nxxiifying object container cor- 
responding to the first field when it made the last modi- 
fication to tiie object or objects. For convenience, an 
update stamp is represented by (skJ}, tj) where skJ| is the 
first field of the update stamp, and tj is the second f ieM 
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of the update stamp. The time stamp In an update 
stamp can be real time, an update sequence number, or 
whatever is meaningful to the application. A series of 
time stamps generated by an object container must be 
consistent in meaning and strictly monotonic while dif- 5 
ferent object containers may have different semantics 
with the time stamps they generate. This is very impor- 
tant when synchronizing between object containers 
across different application systems tjecause it is 
inrpractlcaL to require different application systems gen- 10 
erating time stamps with the same semantics. 
[0076] Using the update stamp representation above, 
the summarizing version vector of an object container or 
the version vector of an object can be represented as 
{(sidi . ti). • • • . (sidj, tj), • • • .(sidp. tp)} or {(sidj. tj) | i = is 
1, 2, ...,n}. The semantics of the summarizing version 
vector of an object container and the version vector of 
an object are similar, except that the version vector of an 
object only reflects that object's current state in its con- 
taining object container other that the current state of 20 
the containing object container. Due to the similarity, 
only the summarizing version vector will be described In 
detail in the following. The version vectors of objects will 
be mentioned only when needed. 
[0077] "The i-tlTcbrr^onent of t^^ 
vector of an object container means tiiat the object con- 
tainer has contained all modifications made by the 
object container with the identifier sidj ip until the time 
indicated by the time stamp tj. For convenience, the 
summarizing version vector of object container j will be 30 
represented as w^. and its i-th update stamp as wf. 
[0078] The size n of the summarizing version vector 
of object container j means tiiat object container j-th 
has contained all the modifications to the objects in it 
made by .the object containers with the identifiers sid^. 35 
sid2, sidn up until the time stamps t^, t2. ... tn respec- 
tively. Based on the descriptions above, several func- 
tions/propositions are defined/^jroved below in order to 
make it possible to compare the state of two entities by 
utilizing summarizing version vectors, version vectors, 40 
and update stamps. An entity hereinafter represents an 
object container, an object, or a differential update. 
[0079] Definition: z = y.getTime(x) is a function 
which returns the time stamp z in y that corresponds to 
the object container with the Identifier x. y represents 45 
the summarizing version vector of an object container, 
the version vector of an object or tiie update stamp of a 
differential update. If x does not appear in y, then the 
returned time stamp z is 0. 

[0080] Definition : Let y^ and yg are either the sum- so 
marizing version vector of an object container, the ver- 
sion vector of an object or the update stamp of a 
differential update, y^ is equal to Y2 if 
yi.getTimc(x) = y2 getTime(x) for any object con- 
tainer's identifier in y^ and Yg. yi is newer ttian yg if y^ is ss 
not equal to yg and y vgetTime(x) >= yg.getTimeCx) 
for any object container's identifier in y^ and yg.y^ is 
older than yg if yi is not equal to yg and 



yi.getTime(x) <= yg getTime(x) for any object con- 
tainer's identifier in y^ and yg. yi conflicts with yg if y^ Is 
neitiier equal to yg. nor newer tiian yg. nor older than y2. 
[0081] Proposition: Let e^ and e2 represent either an 
object container, an object, the base of an object, or a 
differential update and yi and yg are the summarizing 
version vector, the version vector, or the update stamp 
of e-i and eg, respectively, e^ has the current state same 
as or consist witii eg's if y^ Is equal to yg. e^ has tiie cur- 
rent state newer than eg's if y^ is newer tiian yg. ei has 
tiie cun-ent state older than e2's if yi is older than yg. e^ 
has tiie current state conflicting with eg s if y^ is conflict- 
ing with yg. 

[0082] Prove : By definition, if y^ is equal to yg. tiien 
any update contained in is also contained in e2 and 
vice versa. So obviously e^ has the current state same 
as eg if yi is equal to yg. Next assume that y^ is newer 
than yg and tiie current state of e^ is not newer than eg s. 
By definition, if y^ Is newer than yg. then e<| must contain 
updates which are not contained In eg and any update 
contained in e2 must have been propagated into e^ So 
tiie assumption does not hold. The ottier part of the 
proposition can be proved similarly. (Prove ends.) 
[0083] Definition: Let y^ and y2 be the summarizing 
version vectors of object containers ei-and-egrrespec- 
tively, ry is called the common version vector of y^ and 
y2 if and only if ry contains only tiie identifiers of object 
containers tiiat exist Jn both y^ and yg and the time 
stamp in ry corresponding to each of such Identifiers is 
the smaller of the corresponding time stamps in yi and 
y2. 

[0084] Proposition : Let ei and eg be two different 
object containers and yi and yg be the summarizing ver- 
sion vectors of yi and yg, respectively. Further, let ry be 
the common version vector of yi and yg. ry tiien repre- 
sents tiie state from which ei and e2 diverged. 
[0085] Prove : By definition of yi and yg. if an update 
has been contained in botii ei and eg. then it must be 
reflected in both y^ and yg. and therefore the time stamp 
associated with the update must be equal or less tiian 
tiie corresponding time stamps in yi and yg. In other 
words, tiie time stamp associated witii tiie update Is 
equal to or less tiian to tiie smaller of the two corre- 
sponding time stamps in yi and yg. By definition of tiie 
common version vector, the update is reflected in ry 
[0086] If an update Is only contained in either ei or eg. 
tiien tiie time stamp associated witii the update must be 
greater than the corresponding time stamp in the sum- 
marizing version vector of tiie other object container. 
Therefore, the update can not have been reflected by 
tiie summarizing version vector of the object container 
absent it. By the definition of the common version vec- 
tor, the update also can not have been reflected by ry. 
{Prove ends.) 

[0087] It is appreciated that whenever a modification 
to an object is made to an object container, that modifi- 
cation will be reflected into the object container by call- 
ing the put method as shown In Figure 3 on the object 
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container. The put methcxj will in turn cause the object 
container to update its summarizing version vector, 
update the version vector of the object to be modified or 
generate an update stamp associated with the differen- 
tial update to be added, and add the reference to the 5 
modified object or added differential update and the ref- 
erence to the corresponding version vector or update 
stamp to the update log of the object container. The 
update stamp of a differential update means that the dif- 
ferential update was generated by the object container ro 
with the identifier shown in the first field of the update 
stamp at the time shown in the second time stamp in the 
update stamp. 

[0088] Based on the description above, it is realizat>le 
to figure out the difference of an object container from is 
another, detect concurrent update conflicts between two 
object containers, and reduce the number of entries in 
update logs. Let Is denote object container i that is going 
to pull updates from another object container j denoted 
as Rq. The concrete algorithms for the computation 20 
mentioned akxjve are as follows. 
[0089] Difference Computing: - Assume Rs which 
has the summarizing version vector sw^ has received 
the surnmarizing version vector sw* of Ig and the identi- 
fiers E' of the objects which need to be sent to Ig as 2s 
whole objects. Then the common version vector rw^ of 
sw* and sw* can be calculated based on the definition 
above and all the updates need to be sent to Ig are 
determined as follows. 

[0090] First for any object wNch does not support dif- so 
ferential synchronization, the version vector of the 
object is checked. The whole object will be sent as an 
update to \q if its version vector is newer than rw'j. Let 
U1 be the group of updates obtained by the above com- 
puting. 35 
[0091 ] Secondly, for any object which supports differ- 
ential synchronization, the version vector of the base of 
the object is checked. The whole object will be sent as 
an update to Ig If its base version vector is newer than 
rWK Let U2 be the group of updates obtained by the 40 
above computing. 

[0092] Next, for any object which supports differential 
synchronization, if there are differential updates applied 
to it. then the update stamp of each of the differential 
updates is checked. The whole object will be sent as an 4S 
update to Ig if the update stamp of any such differential 
update of the object is newer than or conflicting with rvv*j 
and the identifier of the object is contained in E' or any 
differential update of the object will be sent as an update 
to Ig if the update stamp of the differential update is so 
newer than or conflicting with rWK Let U3 be the group 
of updates obtained by the above computing. 
[0093] Finally, let U be the union of U1, U2 and U3. 
The order of all updates in U is so that if an update 
whose version vector or update stamp is newer than ss 
another than the version vector or update stamp of 
another update then the first update is before the sec- 
ond update. If two updates in U have conflicting version 



vectors or update stamps, then if the two updates are 
differential updates the order between the two updates 
must be consistent with the order of them in the update 
log of Rg otherwise if let v1 and v2 be the version vec- 
tors or update stamps of the two updates, respectively, 
the two updates will be ordered as follows. 
[0094] Sequentially pick up an identifier sli of object 
container in y1 from the beginning toward the end and 
examine the conditions described in the following until 
having found an sli which meets one of the corxii- 
tions. If there exists a sli such that 
v1.getTime(sli)> v2.getTime(sli) then put the update 
with v1 before the update with v2. If there exists a sli 
such that v1.getTime(sli)< v2.getTime(sli) then put the 
update with v1 after the update with v2. One of the con- 
dition will be finally met because no two version vectors 
in the same object container will be the same because 
of the monotonic feature of the time stamps generated 
by the same object container. 
[0095] U is then the set of updates representing the 
difference of Ig from Rg which will be sent to Ig. 
[0096] Concurrent Conflict Detection: - The detec- 
tion of concurrent update conflicts between two objects, 
belonging to Ig and Rg, respectively, is done after Ig 
received an update related to the two objects. 
[0097] * If the received update is a whole object along 
with its version vector, then the version vector of the 
received update is compared with the version vector of 
the object in Ig. If the received object has a version vec- 
tor newer or older than the version vector of the object in 
Ig. then there will be no conflict between the two objects 
and the received ol^ect will either replace the object in 
Ig or be thrown away If the version vector of the two 
objects conflicts, then the two objects are in conflicts 
and the predefined reconcile method will be called on 
the object in the Ig and Rg. ^ 
[0098] If the received update is differential update with 
its update stamp, then the differentia! updates associ- 
ated with the con-esponding object in Ig will be com- 
pared with the common version vector rw'j of the 
summarizing version vectors of I and R. If no differential 
update of the object in Ig is newer than or conflicts with 
then there is no conflict between the object in Ig 
and the con^esponding object in Rg. Othenmse. all differ- 
ential updates of the object in Ig that are newer than or 
conflicting with rw*! conflict witii the received update 
and they will be all passed to the reconcile method of 
the object in Ig to resolve the conflict. 
[0099] Update Log Reduction: - For each of Is and 
Rs, called the first object container, if the other object 
container, called the second object container, is among 
the first object containers selected set of object contain- 
ers that are considered in the process of the update log 
reduction of the first object container, then the summa- 
rizing version vector of the summarizing object con- 
tainer will be recorded in the first object container and 
ttie following steps for tiie update log reduction will be 
executed. Rrst. tiie summarizing version vectors of 
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other object containers that were recorded in the first 
object container are checked. If the sumrnariztng ver- 
sion vectors of all the object containers selected by the 
first object container has been recorded, the latest com- 
mon version vector of the first object container will be 
computed or re-corrputed. The latest comnrwn version 
vector of the first object container computed here con- 
tains only the object container identifiers which are 
included in each of the summarizing version vectors of 
the other object containers recorded in the first object 
container and the summarizing version vector of the first 
object container itself. Each time stairp In the latest 
common version vector of the first server is the smallest 
of the corresponding time stamps in the summarizing 
version vector of the other object containers recorded in 
the first object container and the summarizing version 
vector of the first object container itself. Next, if the lat- 
est common version vector of the first object container is 
updated, all the log entry in the update log of the first 
object container are scanned, and the updates, that is. 
the deletion of whole objects and the records of differen- 
tial ifxlates whose version vector or update stamps 
whose version vectors or update stamps are older than 
^r equal to the latest common version vector of the first 



object container, are purged off from the update log of 
the first object container. As can be seen from its defini- 
tion above, the latest common version vector of the first 
object container represents the latest state of the object 
container which are common to all the other object con- 
tainers selected by the first object container and the first 
object container itself. Therefore, the semantics of the 
purging off of the updates in the update log of the first 
object container is that any update which has propa- 
gated in all the other object containers selected by the 
first object container is eventually removed from the first 
object container. This, in general, can free some of the 
memory and disk space used by the first object con- 
tainer. 

[0100] A program listing in C describing the above 
system is contained in the Appendix 
[0101] Having now described a few embodiments of 
the invention. It should be apparent to those skilled in 
the art that the foregoing Is merely illustrative and not 
limiting, having been presented by way of example only 
Numerous modifications and other embodiments are 
within the scope of one of ordinary skill in the art and 
are contemplated as failing within the scope of the 
invention as defined by the appended claims equivalent 
thereto. 
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primary servers; 

means for automatically synchronizing data at 

said primary servers; 

a number of secondary servers; 

5 means for coupling a first secondary server to 

one of said primary servers by a link; and, 
means at a secondary server for synchronizing 
objects thereat with objects at any primary 
server to which it can be connected, upon 

10 establishment of a link there between. 

2. The system of Claim 1 , and further including a sec- 
ond secondary server and a synchronization link 
between said first and second secondary servers, 

IS whereby sakJ system supports client^en^er and 
peer-to-peer synchronization modes. 

3. A universal system for synchronizing objects at 
servers which accommodates wide area mobile 

20 computing, comprising: 

a network of primary servers; 
high performance reliable links connecting sakJ 
primary^servers; 
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1. A universal system for synchronizing objects at 
servers which accommodates wide area mobile 
computing, comprising: 5S 

a network of primary servers; 

high performance reliable links connecting said 



means for automatically synchronizing objects 
at sakJ primary servers; 
number of secondary servers; 
means for coupling a secondary server to one 
of said primary servers by a link; and. 
means at a secondary server and initiated 
thereby for synchronizing objects thereat with 
objects at any primary server to which it can be 
connected, whereby if said link between said 
secondary server and said primary server is 
less reliable, synchronization m^ nonetheless 
take place when said secondary server deter- 
mines that a reliable link can be established 
between itself and the primary server to which 
it can be connected. 

4. The system of Claim 3. wherein said means for syn- 
chronizing includes means at said secondary sever 
for ascertaining the reliability of said link and for ini- 
tiating synchronization only when a sufficientiy reli- 
able link can be established. 

5. The system of Claim 4. wherein said ascertaining 
means includes means for determining the band- 
width for the transfer of information over said link 

6. The system of Claim 4 wherein said ascertaining 
means include means for ascertaining the available 
resources at said secondary sender. 

7. The system of Claim 3 wherein said synchronizing 
means include means at said second server for 
manually initiating said synchronization. 
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8. A system for synchronizing objects at two servers, 
comprising: 

servers at two separate locations; 
a network linking said servers; 
means at one of said servers for synchronizing 
objects at said servers either on a whole object 
basis or a differential basis; and. 
means for causing said synchronizing means 
to switch between whole object synchroniza- 
tion and differential synchronization. 

9. The system of Claim 8 wherein said means for 
causing said synchronizing means to switch 
includes means for ascertaining the available 
resources at one of said servers and for switching 
to whole object synchronization when resources at 
a server cannot support differential synchroniza- 
tion. 

10. A method for syrrchronizing objects at two servers 
so as to minimize the amount of data transmitted by 
avoiding the necessity for exchanging version vec- 
tors of individual objects, comprising the steps of: 

providing an object container at each of the 
servers, each of the object containers adapted 
to contain an object; 

providing a summarizing version vector for 
each object container that summarizes the 
state of each of the objects at a server, the 
summarizing version vector summarizing the 
state of the object container and having update 
stamps each having a field for the identifier 
associated with the object container and a field 
for a time stamp which corresponds to the last 
time when the object container created, modi- 
fied or deleted any object thereat, the time 
stamp being generated by the object container 
when an object therein is created, modified, or 
deleted; and, 

Initiating synchronizing by transmitting only a 
single summarizing version vector from a first 
server to a second server, and returning 
updates all at once from the second server to 
the first server If the associated version vectors 
of objects at the second server are newer than 
or conflict v\ntii the received summarizing ver- 
sion vector from tiie first server, or if the 
updated time stamps of the individual objects 
at the second server are newer than or conflict 
with the time stamps associated witii the sum- 
marizing version vector from the first server. 

11. The method of Claim 10, wherein said synchroniz- 
ing step includes performing differential synchroni- 
zation based on tiie summarizing version vectors 
and tiie update stamps to create differerttial 



updates, such that tiie differential synchronization 
Is accomplished by transmitting only those parts of 
objects which have changed as indicated by the dif- 
ferential updates. 

5 

12. "me method of Claim 11. and furtiier including tiie 
steps of generating a latest common version vector 
and using tiie latest common version vector to 
purge off selected differential updates. 

10 

13. The mettiod of Claim 10 and furtiier including tiie 
step of restarting a synchronization from the point 
of a previous failure with data from an unaffected 
server, with the point of failure and the existence of 

15 an unaffected server being determined by tiie sum- 
marizing version vectors associated with the serv- 
ers. 

14. The method of Claim 10, and furtiier including tiie 
20 steps of updating both the version vector of an 

object corresponding to an update from a first 
server to a second server, and tiie summarizing 
version vector in the second server immediately 
after the second server receives an update from the 

25 first server, such tiiat synchronization can be 
restored without resending updates which are 
already received by the second server by compar- 
ing the summarizing version vector of the first 
server with the updated version vector of the sec- 

30 ond server, thus to provide fine grain synchroniza- 
tion. 

15. A universal synchronization system in which 
objects which exist at two servers are synchronized 

35 regardless of object type, comprising: 

servers at separate locations, each hikving a 
version of an object and an update vector asso- 
ciated tiierewith; 

40 a network linking said servers; 

means at each server for separating the 
semantics of tiie objects from tiie synchroniza- 
tion including means for extracting object 
updates in a standard format regardless of 

45 object format and means for synchronizing the 

objects at said servers based on a standard 
protocol utilizing said standard format object 
updates, whereby synchronization can take 
place regardless of the form of tiie object to 

so permit synchronization between different sys- 

tems. 

16. A method for propagating updates from a first 
server to a second server and detecting and resolv- 

55 ing conflicts in the synchronization of objects at the 
two servers, comprising tiie steps of: 

sending a summarizing version vector from tiie 
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first server to the second server; 
upon receiving the summarizing version vector 
of the first server, sending the summarizing 
version vector of the second server back to the 
first server followed by all of the identifiers of s 
objects which exist in the second server and 
that can support differential synchronization; 
upon receiving the summarizing version vector 
and identifiers from the second server, deter- 
mining at the first server the Identifiers from the 10 
received identifiers corresponding to which the 
objects do not exist In the first server; 
calculating at tiie first server the common ver- 
sion vector of tiie summarizing version vectors 
of the two servers: is 
determining at the first server all of tiie identifi- 
ers of objects that can support differential syn- 
chronization and which version vectors to the 
bases, absent all of the corresponding differen- 
tial updates, are newer than the calculated 20 
common version vector, the first and second 
determined identifiers of objects being those 
objects which can not realize differential syn- 
^hronization i n the undergoing synchroniza- 
tion, and which therefore must be switched to Is 
whole object synchronization; 
sending the identifiers of objects which must 
switch to whole object synchronization to the 
second server; 

upon receiving the identifiers from the first 30 
server, calculating at tiie second server the 
common version vector of the summarizing 
version vectors of the two servers; 
determining at the second server the identifiers 
of objects different from tiie received identifiers 35 
that can support differential synchronization 
and which version vectors to the bases, absent 
all of the corresponding differential updates, 
are newer than the calculated common version 
vector, the determined objects being those 40 
objects which can not realize differential syn- 
chronization in the undergoing synchroniza- 
tion, and therefore must be switched to whole 
object synchronization; 

adding the received identifiers to the deter- 4S 
mined identifiers as the set of identifiers of 
objects which, if sent from the second server to 
tiie first server, must send as whole objects; 
comparing at the second server tiie version 
vectors of Individual objects. Including those so 
tiiat can not support differential synchroniza- 
tion and those that can support differential syn- 
chronization and which identifiers are in the set 
of identifiers determined by the second server, 
with the summarizing version vector of the first ss 
server; 

extracting the objects which have a version 
vector newer ttian or conflicting with the sum- 



marizing version vector of the first server as tiie 
updates that are tiie whole objects; 
comparing at the second server the update 
stamps of Individual differential updates that 
were applied to the objects at the second 
server which have an identifier not in the set of 
identifiers determined by the second server; 
extracting the differential updates which have 
an update stamp newer than or conflicting with 
the summarizing version vector of tiie first 
server; 

sending all of the exti-acted updates along with 
their conesponding object identifier and ver- 
sion vectors or update stamps from the second 
server to tiie first server in a consistent order; 
upon finishing sending the updates to the first 
server, purging off the latest common ancestor 
version vector of the second server and some 
or all of the differential updates at the second 
server; 

upon receiving an update along with the corre- 
sponding object identifiers and version vector 
or update stamp from the second server, deter- 
jnining wheti ier the rece ived update is a whole 
object or differential update! 
comparing the received version vector with the 
version vector of tiie corresponding object at 
the first server if the received update is a whole 
object and tiirowing away tiie received object if 
the received version vector Is older than or 
equal to the version vector of tiie object at the 
first server; 

replacing the object at the first server witii the 
received object If the received version vector is 
newer than the version vector of the object at 
the first server, or Identifying that there is a con- 
flict between the object at the first server and 
the received object and having the object at the 
first server resolve the conflict If the received 
version vector conflicts with the version vector 
of the object at the first server; 
comparing tiie received update stamp with the 
summarizing version vector of the first server if 
the received update is a differential update; 
throwing away tiie received differential update 
if the received update stanp is older tiian or 
equal to the summarizing version vector of the 
first server; 

otherwise comparing the summarizing version 
vector of the second server with the update 
stamp of each differential update at the first 
server which was applied to the corresponding 
object at the first server; 
extracting all tiie differential updates which 
have an update stamp newer than or conflicting 
with the summarizing version vector of the sec- 
ond server; 

applying the received differential update to the 
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object at the first server if there is no differential 
update extracted at the first server, or identify- 
ing that the received differential update con- 
flicts with the differential updates extracted at 
the first server; 5 
having the object at the first server resolve the 
conflict; 

upon finishing receiving the updates from the 
second server, updating the latest common 
ancestor version vector of the first server; and. 10 
purging off some or all of the differential 
updates at the first server. 
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